A portion of the disclosure of this patent document contains material which is subject to copyright or mask work protection. The copyright or mask work owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright or mask work rights whatsoever
1. Field of Invention
This invention relates to improvements in testing integrated circuits, in general, and to improvements in methods for testing embedded core integrated circuits while preserving the intellectual property contained in the core circuits, that is, protecting the core circuits from being discovered or determined by inspection of the testing software, in which virtual or pseudo pins are used to represent at least a portion of the core circuits to the testing software.
2. Relevant Background
Recently, embedded integrated circuit cores have been increasingly popular. An embedded circuit core is an integrated circuit building block or module that is embedded into a system chip. Examples of such embedded cores include customizable digital signal processors (cDSPs), which may be embedded into a system that is integrated onto a single integrated circuit chip. The DSP may be of a proprietary design, and the peripheral and supporting circuitry may be customized for a particular use or customer.
Presently, some companies sell xe2x80x9cembedded corexe2x80x9d or circuit designs for use by customers who wish to design their own custom circuit content to produce their own customized or application specific integrated circuits (ASICs). As an example, a customer may wish to design its own peripheral circuits for use with a particular DSP core. In practice, the designer of the DSP provides a circuit description of the DSP in a format that will enable the customer to fabricate his desired circuit. The DSP description, however, will ideally be only sufficient to enable the customer to fabricate the custom DSP, together with peripheral circuits of its own design onto an integrated circuit, but does not disclose the specific design and circuitry of the embedded DSP. A chip in which the embedded core is included is sometimes referred to as a system on chip (SOC).
However, using this chip manufacturing technique gives rise to several problems. For example, from a business standpoint, to make the design of a core circuit economically feasible, the design often needs to be reusable in many diverse customer circuit designs. However, the delivery of a complete circuit design to a customer often enables the customer to reverse engineer the circuit, enabling the circuit configuration, and other aspects of the circuit, to be discovered. The customer then has the ability to reproduce the circuit at will, thereby shortening the lifetime during which the core designer can recoup its design and engineering costs. Therefore, unless steps are taken to protect against reverse engineering the core, the value of the intellectual property in the core may be compromised. Such embedded cores in which the owner has one or more intellectual property interests have recently been referred to as xe2x80x9cIP coresxe2x80x9d.
Therefore, when an embedded IP core is delivered to a customer, details of construction of the core are generally not disclosed. The information that is disclosed often is just sufficient to enable the user to interface its own circuitry to the IP core. Thus, previous IP core models often were treated as xe2x80x9cblack boxesxe2x80x9d, in order to protect the IP content embodied in the models. No visibility into the internal structure or circuitry of the models was provided. Thus, for example, the core often may be delivered only as a circuit description, with only the connection pins and required signal parameters thereof being disclosed. However, this makes testing of the embedded core difficult or impossible. However, a properly designed core should be completely tested at least in a netlist version before being delivered to a customer for use with its custom designed circuitry. Thus, ideally, it should be unnecessary for the customer to repeat the core tests, except to the extent necessary to properly test the added circuitry and their interface and operation with the core.
Nevertheless, after an ASIC has been designed and manufactured, the chip should be tested for manufacturing defects. This typically involves first simulating a properly functioning ASIC, developing a variety of input test patterns and applying them to the simulated ASIC, and determining the expected outputs of the ASIC. The input test patterns are then applied to the actual ASIC. The actual outputs are then compared to the expected outputs. Deviations from the expected outputs indicate that the ASIC has a manufacturing defect.
Because of the complexity of the logic buried within the ASIC, an enormous number of test patterns may be required to properly test the integrated circuit device. One technique that has been used to test such integrated circuits is to add xe2x80x9cscan cellsxe2x80x9d to the ASIC at strategic locations throughout the circuit. Scan cells are points at which logic values may be forced into the ASIC (scan writable gates) and/or observed within the ASIC (scan readable gates). Scan cells normally take the form of flip-flops which may be forced to desired logic values from outside the ASIC, or which may be read from outside the ASIC to determine particular behavior of the ASIC, for example after the test inputs have been applied. For instance, some scan cells enable an external tester to preset a counter within the ASIC to a particular count, and to capture values that verify that combinatorial logic derived from the counter outputs is working properly.
In general, in the design of such scan flip-flops, non-scan flip-flops are often converted into scan flip-flops by adding some additional logic gates, often including a multiplexer. The multiplexer selectively allows either the test values or the circuit values to be applied to the scan cell with which it is associated. The multiplexer is operated for example by a selection signal applied to a selected pin of the ASIC.
Strategic placement of scan cells within an ASIC allows the number of test patterns required to fully test an ASIC to be drastically reduced. Scan cells are normally connected in long chains, allowing all of the scan cells to be written or read from using only a few dedicated test I/O pins on the ASIC. This is important primarily because the computer simulations necessary to produce the test patterns and expected resulting outputs require a great deal of computer resources. Without scan cell techniques, simulation times to produce test patterns that adequately test an ASIC would be impractically long. Furthermore, without scan cells some gates within an ASIC may be simply not testable. However, using scan cells it is often possible to develop test patterns that will detect 99% or more of possible gate failures using a set of test patterns that is not impractically long. The fault coverage obtained is the percentage of possible gate failures that will be detected by a given set of test patterns.
Nevertheless, ASIC designs using embedded cores present a challenge to test. To assist the custom designers, embedded cores typically are supplied by the vendor along with a set of test patterns, which, if applied in isolation, will produce 99% fault coverage. However, these patterns cannot usually be applied to the embedded core in isolation, because the core is buried inside the ASIC with no direct access to the corexe2x80x9ds primary inputs and primary outputs. Hence, it is not possible to apply the supplied set of test patterns to the core in isolation unless some mechanism is supplied for accessing the core.
Among the isolation schemes that have been proposed are the use of multiplexed isolation, boundary scan cells wrapped around the core, and core parallel module testing, which includes the use of multiplexers to allow direct access to the circuitry in question. All of these proposed techniques result in area and performance overhead, which may make these techniques unacceptable for many applications.
A second possible type of approach is to generate new test vectors which will be applied at the ASIC level. Test pattern generation software is well known in the art, and is usually provided by third party vendors. Although it is possible for the ASIC vendor to generate a complete set of test vectors to test the customer""s ASIC, many customers demand that third party vendors be capable of taking the customer""s ASIC design and generating test vectors for it, without requiring any further assistance from the vendor.
The input to a test pattern generation program is typically a flattened ASIC netlist. A netlist is a list of circuit elements and their interconnections, and may be manually generated, or may be generated by known software programs for use in other software programs. Of course in a circuit as complex as a DSP, it would be impractical or impossible to manually generate a useful netlist.
The flattened netlist describes the complete ASIC in terms of primitives such as AND and OR gates, and their functional interconnections. The netlist is described as flattened because the cores, which are hierarchical functional blocks, have been reduced to their constituent primitives and interconnections. Using the flattened netlist, the test pattern generation software is able to generate test patterns that will test the ASIC with an extremely high percentage of fault coverage.
The problem with which a present invention is concerned is that of supplying a flattened netlist to the customer from which the third party""s test pattern generator software can generate test patterns to test the entire ASIC, conflicts with the goal of keeping the detailed design of cores confidential. The flattened netlist for the core comprises much of the proprietary design details that the ASIC vendor desires to keep confidential.
Furthermore, in many circuit designs a large quantity of nonproprietary circuitry may be used. In DSP designs, for example, IEEE standard 1149.1 is often followed in the provision of testing circuitry, referred to as boundary scan or xe2x80x9cJTAGxe2x80x9d circuitry. To access the JTAG circuitry, a JTAG Interface circuit is provided, which also accesses the scan chains that are provided in the core. The modeling of the JTAG circuitry is non-trivial.
What is needed, therefore, is a method for enabling a core user to test the core, together with its own added circuitry, without compromising the intellectual property contained in the core, and in particular without unduly complicating the scan model due to the presence of required additional test circuitry, or the like.
In light of the above, therefore, it is an object of the invention to provide a method for enabling a core user to test the core, together with its own added circuitry, without compromising the intellectual property contained in the core.
Intellectual Property (IP) cores lend themselves to easy integration, but not to test. This poses several test challenges in core based/core dominated systems. The methods provided by the present invention allow for the proper use of insertion of test circuitry and automatic test pattern generation (ATPG) tools, when used in the context of core based, or core dominated, digital circuit designs. This leads to significant fault coverage improvements, while at the same time, maintaining protection of the proprietary IP core.
According to a broad aspect of the invention, a method is presented for enabling scan test vectors to be generated by an automatic test vector generating software program for a customer designed integrated circuit having an embedded vendor circuit. The embedded vendor circuit has a proprietary circuit and a nonproprietary circuit. The method includes creating at least one pseudo input to represent at least a portion of the nonproprietary circuit that is not necessary to be exercised by the automatic test vector generating software program to generate test vectors for the customer designed integrated circuit. An output node of the embedded vendor circuit to which an input of the customer designed circuit is connectable is identified. A test netlist is created which represents circuitry that produces output states at the output node which would be generated by the embedded vendor circuit thereat. The test netlist includes at least one pseudo input and the output node, without including a full netlist of either the proprietary or nonproprietary circuits. Thus, scan test vectors for the customer designed integrated circuit can be generated by the automatic test vector generating software program using the test netlist with the output node connected to an input of a netlist representing the customer supplied circuitry.
According to another broad aspect of the invention, a method is presented for generating test vectors to test an integrated circuit having an embedded vendor circuit and customer supplied circuitry. The embedded vendor circuit includes a proprietary circuit and a nonproprietary circuit. At least one pseudo input is created to represent at least a portion of the nonproprietary circuit that is not necessary to be exercised by an automatic test vector generating software program to generate test vectors at least for the customer supplied circuitry. An output node of the embedded vendor circuit to which an input of the customer supplied circuitry is connectable is defined. A test netlist is created which represents circuitry that produces output states at the output node which would be generated by the embedded vendor circuit thereat. The test netlist includes the at least one pseudo input and the output node, without including a full netlist of either the proprietary or nonproprietary circuits. A netlist of the customer supplied circuitry is combined with the test netlist to form a total netlist. And an automatic test vector generating software program is applied to the total netlist to generate test vectors therefor.
According to another broad aspect of the invention, a system is presented for generating a test netlist of an embedded vendor circuit which includes a proprietary circuit and a nonproprietary circuit for use by a customer in adding thereto customer supplied circuitry. The system includes means for creating a test netlist which represents circuitry having at least one pseudo input to represent at least a portion of the nonproprietary circuit that is not necessary to be exercised by an automatic test vector generating software program. When a netlist for the customer supplied circuitry is combined with the test netlist, scan test vectors at least for the customer supplied circuitry can be generated by an automatic test vector generating software program.